With respect to enterprise software, robust applications are those that, when deployed, are capable of providing enterprise systems with highly available and highly scalable service. Such applications must be able to survive system crashes, permit flexible re-deployment on other computers as the system changes and particularly, as the system grows. The semantic requirement for robust applications is that, despite all this dynamic activity, including system crashes, it provides “exactly once” execution semantics. Such an application may start execution on one computer, that system crash, be redeployed on another, etc., and to the application client, it appears like a seamless execution in which the application executed exactly once without crashing or moving, etc.
Application developers naturally tend to let the business logic of the application dictate how the program is structured. This natural programming style has, in the past, interfered with enterprise system requirements for high availability and scalability. An application written in this “natural” way may retain control state necessary for correct and successful execution across transaction boundaries—a “stateful” application. The problem with stateful applications is the risk of losing state when the system on which they execute crashes. This can result in a “semantic mess” that requires human intervention to repair or restart the application, resulting in long service outages.
The classic transaction processing response to this problem is to require that an application be stateless—meaning that no meaningful information is retained across transactions. However, stateless applications force a rather unnatural “string of beads” style of programming where an application must, within a transaction, first read its state from, e.g., a transactional queue, execute its logic, and then commit the step by writing its state back to a transactional queue for the next step. Note here that “state” is not so much avoided as it is made the responsibility of the application program to manage it in a transactional way. Potential performance and scalability problems related to the message and logging cost of two phase commit (2PC) may also be encountered.
Thus, conventionally a system builder is faced with a dilemma and has to choose between either: fast and easy development (resulting in applications that are more likely to be correct applications, implemented in a natural stateful programming style, but which fail to provide availability and scalability), or the high availability and scalability of the stateless programming model (which adds to development time and where correctness is more difficult to achieve because of the intrusion of additional concerns of explicit state management.